云原生安全规划与实践（一）

前言

     在许多组织中，云原生应用开始大规模的部署和使用，云原生的基础架构建设也随之增加。云原生是个相对复杂的技术体系，不仅仅对对于安全部门，对于IT部门同样如此。各个组织对云原生的安全需求不再局限于对容器层面的需求，如何对整个云原生这个全新IT架构和开发流程进行全盘的安全规划是一个巨大的挑战。首先，我们需要了解云原生安全的特点，再进行整体安全规划，最后按照步骤进行实施。

       
       
       

云原生安全的特点  

       

    云原生相对于传统IT基础架构属于重大的一个升级，其安全防护思路也发生了变化，在对其安全建设规划之前，需要了解其特点，才能有针对性的安全规划，云原生安全有如下的特点：

  1      1不可变的基础设施

   “不可变的基础设施”是云原生中非常重要的一个概念，可以说是云原生整个架构的核心思想。从普通认知角度，整个信息系统是动态变化的。所以在不可变的思想下，是相对于可变来理解的，云原生对一个组件的更新是替换，而不是修改。这样的一致性保证了应用的弹性扩容。当然，这也带了效率问题，为了解决效率问题，云原生用容器技术，编排工具、微服务架构和DevOps一系列技术来保证替换和修改的效率。不可变的基础设施理念的贡献不亚于AppStore对智能手机的贡献。在以前可变的时代，混乱是主旋律。

    同时，在不可变的基础设施带来的几个安全防护思路变化：

1) 资产识别的变化

   一个容器中包括的软件及其运行方式，在打包镜像的时已经确定了，镜像是一个全量的软件包集合，对容器内的应用等资产识别，通过镜像便可了解全貌。基于不可变基础设施的思想下，对于一个软件的更新，会生成一个新的镜像，这时已经视为一个全新的镜像。

    在容器运行状态时，需更多关注容器动态的变化，应该从集群视角，通过标签，Namespace等识别资产的业务属性；另外需要对容器运行历史状况进行重点关注，各个架构下资产的生命周期完全不同，物理机是以年为单位、虚拟机是以月为单位、容器以分钟级为单位，而Serverless以秒级为单位。

2) 防护起点的变化

    通俗的理解，云原生架构中的操作系统应该是Kubernetes，而不是主机OS。在云原生中，没有主机的概念，只有节点的概念，这个节点就是一个计算单元，可以是物理机、虚拟机、IOT设备等。所以在节点这一侧的安全防护可以通过收缩风险面来实现，各大云厂商都推出了云原生专用的OS，如CoreOS/Container Linux、Photon OS、RancherOS、Red Hat CoreOS (RHCOS)、Fedora CoreOS等，这些专用操作系统极度精简，只保证基本的Kubernetes能运行，要求其他所有第三方的应用都运行在容器中，这一层的安全风险可以降到极小。每一个组织通过最小授权原则，都可以基于标准的操作系统进行加固后，制定自己的云原生OS，从而解决OS一层的安全问题。缩小风险面的同时，减少管理成本。

   所以云原生安全起点应该是Kubernetes，从Kubernetes的容器层面向下覆盖节点安全，向上覆盖微服务安全来进行，而不是从底层的节点侧向上覆盖。因为节点向上的覆盖能力不足，特别是针对集群、网络策略和微服务等云原生特有的组件和功能防护。

2
边界的变化

    云原生整个架构是服务云原生应用，以容器为主的虚拟化技术构建的。秉承了软件定义一切的思想，相对于传统架构，其边界变得更加模糊：

    在传统IDC的环境中，系统的边界非常清晰，以网络设备上的边界划分为主。对外的边界由防火墙，路由器等来实现；内部的边界以VLAN等措施来保证。所以传统IDC是以物理的网络设备作为边界区分，区分的标记主要使用MAC地址，IP地址。

   在以虚拟机为主的云计算环境中，以虚拟机为最小单元，以虚拟化网络的访问控制措施作为边界划分，颗粒度到虚拟机级别，以IP地址或者内部域名来识别不同资产。

   而在云原生环境下，资产视角变成业务视角和应用视角，主要通过Namespace进行区隔，而识别资产的方法主要以Label，Tag等标签为主。所以整个边界变得模糊而且更细粒度，优势是天然对业务和应用进行了区分，但同时为安全的控制和管理带来复杂度，当前安全防护手段的基础还是以IP或域名为主，这种变化势必需要调整安全防护措施。

   另外云原生整个管控措施是基于白名单机制的，包括Kubernetes支持的NetworkPolicy就是白名单机制，云原生架构下，是基于零信任的思路来进行防控的，所以云原生是零信任在生产环境下落地实现的最佳IT架构。

3
高度自动化的流程

    在上文中提到DevOps保证了云原生应用发布效率，安全防护往往和效率有一定冲突的，传统的安全对效率的影响在非全自动化流程中可能不明显，比如业务上线的安全测试和检测一般是在QA完成后进行，然后安全测试完再确认上线。这些工作通过内部邮件来流转的时候，内部对其及时性有一定的容忍度。但在云原生下，DevOps作为云原生应用的生命周期管理流程，安全管控需要无缝植入到这个流程中，也就是现在流行的DevSecOps，DevSecOps作为一个大的体系，除了代码安全测试，还应包括制品库安全管理，运行安全策略等等。所以将云原生安全产品或者工具嵌入到DevOps流程，成为了一个必选项。

4全新的攻击手段

    据我们的研究分析和检测，针对云原生的攻击手段开始丰富起来，无论是前两年爆出的特斯拉集群入侵事件，Docker官方镜像仓库镜被投毒等，今年开始，对于云原生的攻击开始增多，由于当前云原生系统普遍安全防护手段欠缺，攻击得手率极高。在今年的HVV中，开始出现通过容器攻击得分的情况也直接说明问题。在整个云原生安全这一块的攻防不对等的情况比其他架构下严重得多。在上一个月ATT&CK推出了专门针对容器的攻击模型：

    更多攻击方开始把注意力转移到针对云原生系统的攻击，云原生系统被攻击后带来的损失会更大，这种攻击非常容易通过一个点的失陷，通过南北及东西向的移动导致整个集群被入侵。

后记

   云原生相对于传统云计算的架构发生了较大变化，我们需要了解云原生安全的特点，才能针对性的进行安全规划和建设。本文先介绍了云原生的安全特点，后续会继续谈谈云原生的安全如何规划以及具体的落地措施。

    针对于云原生安全的特点，小佑科技提供针对云原生安全完整的安全架构，解决方案覆盖容器安全、编排安全、微服务安全和DevOps。